Oracle TimesTen In-Memory Databaseトラブルシューティング・プロシージャ・ガイド

レプリケーションまたはXLAのパフォーマンスが悪い

この項では、レプリケーションのパフォーマンスに影響する可能性がある問題について説明します。ログ・バッファが小さすぎたり、ディスク上のログ・ファイルから読み取ると、レプリケーションとXLAアプリケーションの両方のパフォーマンスに影響する可能性があります。


考えられる原因	対処
ネットワークが遅い	「ネットワークの帯域幅を確認する」を参照
RETURN RECEIPTを使用している	「RETURN RECEIPTブロッキングの使用を確認する」を参照
レプリケーション・スキームの効率が悪い	「レプリケーションの構成を確認する」を参照
ログ・バッファが小さすぎる	「ログ・バッファのサイズを確認する」を参照
ディスクの書込み頻度が高いか、または効率が悪い	「永続性の設定を確認する」を参照
ログ・バッファではなくディスク上のログ・ファイルからの読取り	「ログ・ファイルからの読取りの有無を確認する」を参照

ネットワーク帯域幅を確認する

通常、レプリケーション・エージェントはネットワーク接続を介して通信を行います。10MB/秒（たとえば、LANで一般的な100 Base-Tイーサネットなど）より遅いネットワークでレプリケートを実行する場合、トランザクションの負荷をネットワークの利用可能な帯域幅に合わせるように注意する必要があります。詳細は、『Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド』のネットワーク帯域幅要件に関する項を参照してください。

RETURN RECEIPTブロッキングの使用を確認する

すべてのトランザクションについて受取りの確認を必要とする場合以外は、RETURN RECEIPTブロッキングを無効にしてください。すべてではなく、一部のトランザクションについて受取りの確認が必要な場合は、RETURN RECEIPT BY REQUESTを設定して、ttRepSyncSet()プロシージャをコールし、特定のトランザクションに対するRETURN RECEIPTサービスを有効にします。詳細は、『Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド』のリターン・サービスの使用に関する項のRETURN RECEIPT BY REQUESTの説明を参照してください。

注意: 複数のアプリケーション（またはスレッド）でデータ・ストアを更新している場合、RETURN RECEIPTによるパフォーマンスの低下はそれほど問題ではなくなります。トランザクションでRETURN RECEIPTを使用する必要がある場合、複数のスレッドを使用してデータ・ストアを更新することで、アプリケーションのパフォーマンスを改善できます。各スレッドは受取りの確認のためにブロックする必要はありますが、それ以外のスレッドは自由に更新できます。

レプリケーションの構成を確認する

前述のRETURN RECEIPTの設定に加えて、レプリケーション・スキームの構成に関するその他の多くの要因が、レプリケーションのパフォーマンスに影響を与える可能性があります。『Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド』のパフォーマンスとリカバリのトレードオフに関する項で説明しているように、データ・ストアのフェイルオーバーとリカバリを効率的に実行できることと、レプリケーションのパフォーマンスのどちらを優先するかの比較検討が必要になる場合もあります。

『Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド』の次の項も参照してください。

効率性および経済性

直接レプリケーションまたはプロパゲータ

ログ・バッファのサイズを確認する

『Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド』のディスクベース・ロギングの属性の設定に関する項で説明するように、ログ・バッファの設定値が小さすぎると、レプリケーションのパフォーマンスに影響する場合があります。LogBuffSize DSN属性のサイズを大きくしてみてください。

永続性の設定を確認する

レプリケーションのELEMENTに対してTRANSMIT NONDURABLEを設定して、ログをディスクにフラッシュする操作をレプリケーション・サイクル（『Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド』のレプリケーションの動作に関する項を参照）から取り除くことで、レプリケーションのパフォーマンスを改善できます。詳細は、『Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド』の送信永続性の設定に関する項を参照してください。

また、レプリケーション・スキームでDURABLE COMMITオプションを有効にしても、パフォーマンスに影響があります。詳細は、『Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド』のDURABLE COMMITに関する項を参照してください。

ログ・ファイルからの読取りの有無を確認する

状況によっては、マスター・レプリケーション・エージェントのTRANSMITTERスレッドやXLAアプリケーションのttXlaNextUpdate()コールなどのログ・リーダーが、アプリケーションによるデータ・ストアへの書込みの更新を処理しきれない場合があります。通常、レプリケーションおよびXLAリーダーは、メモリー内のログ・バッファから更新レコードを取得します。リーダーがアプリケーションの更新を処理しきれない場合、バックログがクリアできるようになるまで、ログ・ファイルがディスクに蓄積されることがあります。この場合、リーダーは、非常に遅いディスク上のログ・ファイルからトランザクションを読む必要があります。ログ・ファイルからの読取りを検出したら、ログ・リーダーが処理できる速度までアプリケーションの更新速度を下げてください。

アプリケーションでは、SYS.MONITOR表のエントリLOG_FS_READSを追跡することで、ログ・リーダーがメモリー内のログ・バッファではなく、ディスク上のログ・ファイルから更新レコードを取得しているかどうかを監視できます。たとえば、データ・ストアMASTERDSNのLOG_FS_READS値は、次のttIsqlコマンドで確認できます。

% ttIsql -v1 -e "select log_fs_reads from monitor; quit;" -connStr dsn=MASTERDSN

LOG_FS_READSカウンタが増加している場合、ログ・リーダーはログ・ファイル内のバックログより遅れている、バックログをクリアしています。

より完全にレプリケーション・プロセスを監視するには、次のような簡単なシェル・スクリプトを作成します。

!/bin/sh trap exit 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 DSN=$1 while [ 1 ] ; do date ttRepAdmin -receiver -list -connStr dsn=$DSN echo -n "Log reads from disk: " ttIsql -v1 -e "select log_fs_reads from monitor; quit;" -connStr dsn=$DSN echo ttRepAdmin -bookmark -connStr dsn=$DSN sleep 15 done

例4.13

たとえば、前述のスクリプトがmonitorLogという名前で、レプリケーション・スキームによって、MASTERDSNデータ・ストアからSUBSCRIBER1DSNデータ・ストアにレプリケートが行われるとします。この場合は、次のように入力して、トランザクションのステータスを確認できます。

$ monitorLog masterdsn

This will generate output similar to:

Mon Aug 2 10:44:40 2004 Peer name Host name Port State Proto ---------------- ------------------------ ------ ------- ----- SUBSCRIBER1DSN MYHOST Auto Start 12 Last Msg Sent Last Msg Recv Latency TPS RecordsPS Logs ------------- ------------- ------- ------- --------- ---- 00:00:05 - -1.00 -1 -1 1 Log reads from disk: < 0 > Replication hold LSN ...... 10/2656136 Last written LSN .......... 10/4015824 Last LSN forced to disk ... 10/3970152

[Control]キーを押しながら[C]キーを押して終了するまで、スクリプトによって、更新されたステータスが15秒毎に出力されます。

例4.13の出力では、日付の後にサブスクライバ名、ホスト名などが表示されます。その後には、待機時間、速度に関する情報、およびこのサブスクライバに代わって保持されているログ・ファイルの数が表示されます。各値の具体的な意味は、『Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド』のコマンドラインからのttRepAdmin -receiver -listの項を参照してください。ここでは、Last Msg SentとLogsの値です。Last Msg Sentの値は、最終メッセージがマスターによってサブスクライバに送信されてからの経過時間を示します。Logsの値は、ライターが使用する現在のログ挿入ポイント（Last written LSN）以降で、レプリケーション・ログ・リーダーより遅れているログ・ファイル数を示します。

例4.13で示すように、通常、Logsの値は1です。Logsの値が一定間隔で増えることは、待機時間が増え、ディスクからログが読み取れることを示します。

注意: LogBuffSizeがLogFileSizeよりも大きい場合、Logsの値が増加しても、ログ・リーダーがログ・ファイルから読取りを行っているとはかぎりません。これは、データをファイル・システムに書き込む前に、未処理のデータが1ログ・ファイル分を超えることをログ・マネージャが許可しないためです。ログ・マネージャがデータを書き込んだ後は、ログ・リーダーから直接読み取れるように、データはログ・バッファ内に残ります。したがって、LogBuffSizeがLogFileSizeよりも大きい場合、Logsの値のみでは、ログ・リーダーがメモリーとディスクのどちらから読取りを行っているかを判断できない場合があります。

次のコマンドの出力について考えます。

ttRepAdmin -bookmark -connStr dsn=$DSN

『Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド』のコマンドラインからのttRepAdmin -bookmarkの項で示すとおり、ログ・ファイル数とログ・マネージャによって設定されるブックマークの位置が表示されます。Replication hold LSN とlast written LSN との差異は、サブスクライバに送信されていないトランザクション・ログのレコード数を示します。これらの値の差異が一定間隔で増加する場合は、レプリケーションの待機時間が増え、ログ・ファイルの読取りが発生する可能性があることを示します。

例4.14

この例では、LogBuffSizeは16MB、LogFileSizeは8MBと想定しています。次の出力は、ログ・リーダーがログ・バッファの容量よりも約1.8MB遅れており、ログ・ファイル14および15からの読取りが必要なことを示しています。

Peer name         Host name                Port    State   Proto 
----------------  ------------------------ ------  ------- ----- 
SUBSCRIBER1DSN    MYHOST                   Auto    Start   12 
Last Msg Sent Last Msg Recv Latency TPS     RecordsPS Logs 
------------- ------------- ------- ------- --------- ---- 
00:00:03      -               -1.00      -1        -1    4 
Log reads from disk: <20> 
Replication hold LSN ...... 14/7007464 
Last written LSN .......... 17/465336 
Last LSN forced to disk ... 17/456152